The present invention relates to on-demand access to processing capacity of a processing resource. More particularly, and not by way of limitation, the present invention is directed to a system and method for providing an integrated software license for on-demand and scalable processing capacity along with an on-demand and scalable reliability Service Level Agreement (SLA).
Traditionally, on demand access to processing capacity (of a processing resource) can be provided through capacity software licensing as discussed, for example, in U.S. Pat. Nos. 7,146,496 and 7,493,488. In many applications, a computerized system provides a functionality of interest (e.g., accounting computations, customer data record management, call traffic management for a cellular wireless network, etc.) over a number of distributed Processing Entities (or Processing Elements) (PEs). Thus, the capacity of the functionality of the system is provided by a group of capacity-shared PEs in which the PEs may have different capacity ratings, load distribution among the PEs may be imbalanced, and the PEs may or may not be geographically (or physically) co-located with one another. FIG. 1 illustrates an exemplary capacity software (SW) licensing mechanism in which the whole unit (identified by reference numeral “10”) of the capacity of primary function of the computerized system is subdivided into chunks of smaller capacity units (some of which are identified by reference numerals “12” through “15”) controlled and managed via respective capacity software licenses. A user/customer can purchase any number of capacity software licenses on demand and the system capacity usage is then policed in real time, near real time, or through a regular periodic auditing process to ensure conformance with the number of purchased capacity licenses. For example, in FIG. 1, the customer is shown to have purchased two capacity SW license keys for capacity units 12-13 (illustrated by darkened blocks), but can as well purchase any desired number of software licenses (from license key 1 to license key N) any time on demand up to the system maximum capacity.
In distributed PEs systems (e.g., the Mobile Switching Center (MSC) pool or Serving General Packet Radio Service Support Node (Serving GPRS Support Node or SGSN)/Mobility Management Entity (SGSN/MME) pool systems—collectively called Core Network (CN) pool), the capacity of the functionality of the system may be provided by a group of capacity-shared PEs. The CN pool provides service providers great value on the network level such as, for example, dynamic capacity management, simplified network planning, network resiliency and geographical redundancy. The CN pools may have a “built in” system-level redundant capacity that can be accessed when there is a failure or outage of one or more PEs within the system. According to the current industry practice, the distributed CN pool's spare capacity is engineered using the N+1 redundant capacity level so that the system will not suffer any outages with one PE failure. This level of redundant capacity normally leads to a huge improvement in the CN pool's (or any such distributed PEs system's) reliability level relative to the reliability level of the individual members (e.g., an individual PE) of the CN pool. Usually, the reliability improvement is at a level that far exceeds both the service provider and product supplier reliability targets.
Another way to enable on demand access to capacity is through cloud computing. Cloud computing allows on demand network access (i.e., pay-as-you-go) to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) providing scalable capacity on demand and a blanket level of guaranteed quality of service (QoS) or reliability Service Level Agreement (SLA). Cloud computing frees cloud users from the costly hardware and software acquisition, installation, and maintenance tasks through the use of simpler hardware that accesses cloud provider's vast network of computing resources (comprising distributed PEs) which share cloud users' workload. The sharing of computing resources reduces the cost to both the cloud user and the cloud provider. As mentioned, cloud provider offerings, such as cloud utility computing, typically include SLAs.
An example of cloud computing may be a telco cloud which tackles the challenges around the Software as a Service (SaaS) aspect of cloud computing by offering a core network and application layer products as SaaS. Products that may be part of such a telco cloud include, e.g., the MSC server, the Internet Protocol (IP) Multimedia Subsystem (IMS) core, the SGSN control plane, and application layer products such as Business Communication Suite (BCS). A telco cloud project may support multiple automated and isolated product deployments (multi-tenancy) on Infrastructure as a Service (IaaS) clouds. These IaaS clouds may be hosted by cloud providers, operators, or other 3rd parties. In cloud computing, individual application layer products such as the MSC server may be migrated into instances of software-based Virtual Machines (VMs) that may be hosted on network of shared hardware infrastructure in the cloud using virtualization technology. Other examples of cloud computing are Amazon Web Services (AWS), Google Application Engine (GAE) for businesses, and Microsoft Azure. Many Tier 1 carriers such as AT&T and Verizon Business also have commercial cloud computing offerings.
As mentioned, cloud computing is a model for enabling network access to a shared pool of resources. Cloud infrastructure may provide resources needed for enabling cloud services. A virtualized environment could be configured such that a hardware failure can fail over to one of a set of backup PEs allowing for many-to-one failover in a virtual environment in the cloud. FIG. 2 depicts how a hardware failure may be handled in a VM-based cloud 20. The cloud 20 may implement virtualization to partition hardware processing resources 22-24 (such as, for example, Central Processing Unit (CPU), memory, storage, and Input/Output (I/O) units) to execute different Operating Systems (OS) and corresponding applications (App) on the same hardware. For example, in FIG. 2, operating systems 25-27 and corresponding applications 28-30 may constitute a set of VMs 32 that is executed on hardware 22, operating systems 34-36 and corresponding applications 37-39 of the VMs 42 may be executed on hardware 23, and operating systems 44-46 and corresponding applications 47-49 of the VMs 50 are executed on hardware 24. In FIG. 2, the VMs 32, 42, 50 may turn hardware into software instances, and hypervisors 54-56 may map corresponding VMs 32, 42, 50 to physical hardware (HW) resources. In FIG. 2, each set of VMs, hypervisor, and related hardware may be considered a Processing Entity (PE) as indicated by reference numerals “58,” “59”, and “60.” It is observed here that in other systems or configurations involving distributed computing/processing, a PE may constitute different elements than those shown in FIG. 2. As illustrated in FIG. 2, when there is a hardware failure in the cloud 20 (e.g., failure of hardware resource 22), the execution of VMs 32 associated with the hardware 22 may be carried over to a set of backup PEs 59-60 such that application 28 in the failed PE 58 may be executed through application 37 in the backup PE 59, and applications 29-30 in the failed PE 58 may be executed through respective applications 47-48 in the backup PE 60.